Cloud computing has become a widely adopted approach which allows an enterprise to obtain access to large amounts of computing resources. One of the primary technologies underlying cloud computing is virtualization. Virtualization allows a physical computing server to host multiple virtual machine instances, each of which executes as an independent computing system with virtual hardware components, such as a CPU and memory, managed by an operating system. Once launched, an enterprise can run applications on a virtual machine instance in the same manner as applications running on a physical computing system or server used by the enterprise. Because additional virtual machine instances can be launched on demand, cloud computing allows an enterprise to obtain computing resources as needed without having to invest and maintain an underlying physical computing infrastructure.
In addition to providing compute services (e.g., virtual machine instances), a cloud computing provider may offer a variety of other computing resources and services to enterprise customers. For example, the service provider may offer database services, persistent storage services, networking services, load balancing, auto-scaling, messaging services, cloud formation services, monitoring services etc., as part of a cloud based services offering.
Regardless of whether an enterprise decides to host a computing service on an enterprise computing infrastructure or using virtualized services from a cloud computing provider, configuring the underlying systems and services used to host a computing service can be a challenging task. As a result, engineers can spend several days configuring the systems and services needed to host even a simple service. Further, once deployed, updating the application, changing the configuration of the underlying systems and services, or deploying the application to additional systems or locations can also require substantial amounts of engineer time. For example, assume an enterprise wants to deploy a retail shopping website, where the website is backed by web-servers, application servers, and database applications deployed using services offered by a cloud computing provider. Doing requires engineers to, among other things, configure and provision a variety of virtual machine instances (or classes of instances) with the desired web and application server applications, provide the content for these systems, configure network addresses, configure database and storage services, provision security mechanisms (e.g., provisioning SSL certificates on all public facing systems), configure administrative and role based access controls, configure and launch load balancing systems, scaling groups, as well as configure monitoring, logging, and reporting applications. Once deployed, adding features or updating the software used to provide a public facing service (e.g., the retail web site) can require similar levels of configuration and provisioning.
Similar challenges are faced by the cloud computing provider in exposing the underlying cloud computing services used by the enterprise deploying the retail website. For example, launching a compute service, auto scaling service, database service, storage service, etc., requires engineers at the cloud computing provider to separately configure and provision the underlying computing systems and applications used to provide each cloud computing service.
Given the complexity of deploying even a relatively straightforward computing service, an enterprise will frequently develop a deployment or rollout process to manage how a new service is launched (or launched at a new location). The deployment process may generally specify a configuration for the service being provisioned. In some cases, the deployment process may also specify a set of testing stages—often referred to as a deployment pipeline—used to stand up a public facing service (e.g., integration tests, followed by alpha, beta, and gamma stages) along with success, failure, or rollback conditions for each stage. The same deployment pipeline may be used to update the applications, systems, or services used to provide the public facing service or when the underlying systems or services used to provide such a service are changed. Similarly, the service provider may define a deployment pipeline used to push changes in the application source code (e.g., bug fixes or new features) out to the production systems hosting a given service. Such a pipeline may specify integration tests, alpha, beta, and gamma testing stages as well as workflows for approving or completing each stage or rolling an application back to a prior state if a new version of the application being pushed into production fails an approval requirement or proves to be disruptive to the service.
However, this approach leaves it to engineers managing a given deployment pipeline to both configure and provision each system and service correctly, as well as to follow any enterprise best practices in composing a deployment pipeline. Doing so can lead to inconsistent results across different deployment pipelines for otherwise similar services or applications. Further, this approach limits ability of an enterprise to reuse or standardize a deployment process. Instead, engineers frequently, “cut, paste, and customize” elements of an existing deployment pipeline for use with a new service (or new instances of an existing service). A similar approach occurs when an enterprise relies on a change management process to update the features or requirements of an application or service. In such cases, engineers have to spend substantial amounts of time to plan how to deploy and test an update to the systems or applications providing a public facing service. Accordingly, for an enterprise managing even a handful of deployment pipelines, maintaining, updating, or changing the set of deployment pipelines as best practices evolve or building new deployment pipelines for new computing services can require substantial engineering resources. As a result, managing a set of deployment pipelines can become a distraction for the enterprise in improving the quality or features of the actual applications or services being deployed through a deployment pipeline.